Our project started with Fred Smith taking on the responsibility of managing the project. Our other program managers took on roles to help the project be successful. William Arnold will be the software engineering lead and I, Tom Jones, will take on the responsibility of the risk manager.
As the project started out we had a team meeting to discuss the purpose of the project with the team and to get everyone in the right frame of mind. We discussed the top goals of the project and identified the risks that the program management team came up with. We decided to rent out a large conference center to hold this initial meeting and get the processes organized. We are dedicating the week to refining the goals of the project and ensuring that we start off on the right foot.
To get the groups going we just had an overview type of meeting and broke up the employees into their respective teams. Each team had their own room to discuss the areas they would cover and get a solid understanding of what their part in the project was.
We had the following team break downs: software engineering, product engineering, and network engineering. These groups are the main focus of the project in the initial stages. We have some of the repair technicians assigned to each group so they can add some insight to each of the groups. We also created team dependencies so everyone knows who is dependent on whom.
Team Dependencies
For the initial stages of the project we are going to operate out of our current repair facility and at the half way point we will start to move out to our geographical areas. Members of the teams are already selected to move to these areas and setup when the time in the project calls for it.
Each team went to different parts of the conference center to discuss the details of their sections. We had several group and individual meetings and came up with the initial risk list and team tasks to take back with us to start the project.
Task List
Week of 26 July
After the initial conference we got back to the office and started to develop the risk action plans and scenarios to give to each of the teams. Our software team started to generate program specifications, our network team started to define requirements for network support, and the engineering team started to make contacts with Dapple and get the product specifications and repair outlines.
These actions started attacking our top five risks in the project. At this point it is too early to know if there are any issues so everything seems to be going smoothly.
Here are the risks we identified for the project
Here are the Risk Scenarios (For Critical and High Risks Only)
Risk Scenario for Risk ID – P-01 Product Guide Delivery
If the product guide is not created for a repair item that we receive, it must be assigned to our most skilled technician. If a novice technician receives the device we can have to potential of the item becoming un-repairable. If the item is not under warrantee repair status and the technician cannot repair the item due to his lack of knowledge and no guidance form a repair guide the company must absorb the cost of item replacement.
Risk Scenario for Risk ID – N-01 Network Infrastructure
The decision to outsource our network infrastructure is an important one. If we outsource it we have a better chance of keeping the network maintained at a lower cost than keeping a staff on hand to keep the network running. However, it is important to have network expertise at each operating location to maximize repair response time if a problem occurs. By having an outside agency maintaining our main server we can have issues of limited response time. Lack of network availability can impact new customer repair requests and customer repair inquires.
Risk Scenario for Risk ID – S-01 Software Database Normalization
Having a normalized database is important to overall database efficiency. Lack of normalization can impact database queries and have a duplication of data. It is in the best interest of the project to ensure we have a well thought out database design to maximize database operations.
Risk Scenario for Risk ID – N-03 Network Outage
Network outages can disrupt the repair process. The goal of the network infrastructure is to minimize redundancy and centrally locate software resources. Having all of the software updates located on the main data server could cause repair actions to be stalled and a customer receiving their device out of the specified repair window. To mitigate this possibility item repair will be distributed to each repair facility and the correct software will be loaded locally to avoid this potential possibility.
Risk Scenario for Risk ID – S-03 Software Repair Guide
Once the repair guide is finalized, it needs to be integrated into the repair software process. By not integrating the repair guide in the repair software the technician will have to locate the latest guide version on the network. If the guide is in a hard copy version and the technician uses an outdated version it could cause damage to the device and require an unnecessary item replacement.
Risk Scenario for Risk ID – S-04 Software Repair Process
The software development of the repair program must be closely integrated in the repair process. The goal is to walk the technician through each step in the process and make the repair as efficient as possible. If the software is not integrated in the repair process the technician may skip a critical repair step and cause damage to the item or the potential loss the user’s data.
Risk Scenario for Risk ID – S-05 Software Documentation Process
The documentation of the user’s device is an important aspect of our repair facility. By keeping detailed records of repair actions we can maintain a history of repair actions against devices and look for trends of repair actions. We can give these repair trends to the device engineers and help identify potential problems the devices might have. By not documenting the process in a standardized format the potential of reliability analysis can be lost and problem trends will not be clearly identified.
Risk Scenario for Risk ID – R-01 Repair Loss
If an item is not properly tracked once it is received and not assigned to the correct repair technician the item may be lost in the system. It can potentially breach our 10 day service window and cause the customer frustration by not having their item in a timely manner. In addition the item will have to be replaced and the user’s data will be lost. This could be a potential financial loss to the company and a credibility loss from the customer.
Risk Scenario for Risk ID – P-04 Product Guide Development
When new products are developed and released it is in our best interest to get a prototype so we can develop a repair guide and have it completed before we start receiving the new items. This situation is very similar to what would happen in the risk scenario for Risk ID P-01.
We also developed this status sheet for the team to track our progress
Journal Entries
Progress of the project
Week of 5 Jul 2010
Our project started with Fred Smith taking on the responsibility of managing the project. Our other program managers took on roles to help the project be successful. William Arnold will be the software engineering lead and I, Tom Jones, will take on the responsibility of the risk manager.
As the project started out we had a team meeting to discuss the purpose of the project with the team and to get everyone in the right frame of mind. We discussed the top goals of the project and identified the risks that the program management team came up with. We decided to rent out a large conference center to hold this initial meeting and get the processes organized. We are dedicating the week to refining the goals of the project and ensuring that we start off on the right foot.
To get the groups going we just had an overview type of meeting and broke up the employees into their respective teams. Each team had their own room to discuss the areas they would cover and get a solid understanding of what their part in the project was.
We had the following team break downs: software engineering, product engineering, and network engineering. These groups are the main focus of the project in the initial stages. We have some of the repair technicians assigned to each group so they can add some insight to each of the groups. We also created team dependencies so everyone knows who is dependent on whom.
Team Dependencies
For the initial stages of the project we are going to operate out of our current repair facility and at the half way point we will start to move out to our geographical areas. Members of the teams are already selected to move to these areas and setup when the time in the project calls for it.
Each team went to different parts of the conference center to discuss the details of their sections. We had several group and individual meetings and came up with the initial risk list and team tasks to take back with us to start the project.
Task List
Week of 26 July
After the initial conference we got back to the office and started to develop the risk action plans and scenarios to give to each of the teams. Our software team started to generate program specifications, our network team started to define requirements for network support, and the engineering team started to make contacts with Dapple and get the product specifications and repair outlines.
These actions started attacking our top five risks in the project. At this point it is too early to know if there are any issues so everything seems to be going smoothly.
Here are the risks we identified for the project
Here are the Risk Scenarios (For Critical and High Risks Only)
Risk Scenario for Risk ID – P-01 Product Guide Delivery
Risk Scenario for Risk ID – N-01 Network Infrastructure
Risk Scenario for Risk ID – S-01 Software Database Normalization
Risk Scenario for Risk ID – N-03 Network Outage
Risk Scenario for Risk ID – S-03 Software Repair Guide
Risk Scenario for Risk ID – S-04 Software Repair Process
Risk Scenario for Risk ID – S-05 Software Documentation Process
Risk Scenario for Risk ID – R-01 Repair Loss
Risk Scenario for Risk ID – P-04 Product Guide Development
We also developed this status sheet for the team to track our progress
And this one for management to get a quick status
**Here are the Risk Action Plans**
Project Home Next Section